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REMARKS 

This amendment is responsive to the Final Office Action dated November 28, 2008. 
Applicant has not amended the claims. Claims 1—40 are pending. 

Claim Rejection Under 35 U.S.C. $ 103 

In the Final Office Action, the Examiner rejected claims 1 - 10, 1 5 - 23, and 27-37 
under 35 U.S.C. 103(a) as being unpatentable over Viswanath (US 2004/0019670 Al) in view of 
Kanada et al (US 2002/0194317 Al). Applicant respectfully traverses the rejection. The applied 
references fail to disclose or suggest the inventions defined by Applicant's claims, and provide 
no teaching that would have suggested a rational reason to lead a person of ordinary skill in the 
art to arrive at the claimed invention. 

Claims 1,15, and 28 

With regard to claim 1, for example, Viswanath modified in view of Kanada still fails to 
teach or suggest applying an implementation-specific configuration policy to validate the 
changed candidate configuration data, wherein the implementation-specific configuration policy 
comprises a set of rules representing the specific operational requirements of the particular 
networks within which the network device operates, as recited by independent claim 1 . 

As explained in Applicant's prior communication, Viswanath describes "semantic 
verification and syntactic validation mechanism for server configuration information" 1 used to 
"verify and validate changes to configuration information" 2 Applicant further pointed out that 
syntactic validation, as described in the reference and as is well-known in the art, is a grammar 
check used to ensure the proper order of terms. Semantic verification of configuration options 
involves testing whether the terms and syntax used in the option are intelligible given the device 
being configured. In the case of a router, semantic rules in the form of a configuration policy are 
enforced to prevent configuration of the router into an unstable state, or into sub-optimal 
operation. 3 

In contrast, implementation-specific configuration policies recited in Applicant's claims 
are used to enforce rules promulgated at a higher level so as to enforce requirements that are 

' Viswanath at Abstract. 

2 Id. 

3 Application f [0007]. 
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quite different from syntactic or semantic validation. Rather than being concerned with grammar 
or the intelligibility of configuration options, implementation-specific configuration policies are 
specified based on the particular needs of the network in which the device is to be deployed . 
Applicant's patent application describes implementation-specific configuration policies as 
defined by a network manager in response to, for example, client requirements relating to 
particular requirements of a computer environment, service level agreements with end users, and 
other requirements. 4 These implementation-specific options and the policies that enforce them 
therefore "vary depending on the specific needs of the networks within which the devices 
operate. 5 Thus, while a candidate configuration (i.e., updated configuration to be committed) 
may be syntactically and semantically correct, it may nevertheless violate one or more 
implementation-specific configuration policies for a given network environment. 

Although the Applicants submit that the use of the phrase "'implementation-specific 
configuration policy" is adequately defined in the specification, Applicants nevertheless 
previously amended independent claims 1,15, and 28 to clarify the distinction between this type 
of configuration policy and the syntactical and semantic rules found in a typical configuration 
policy. In particular, the amended claims state that an implementation-specific configuration 
policy comprises a set of rules representing the specific operational requirements of the 
particular networks within which the network device operates. 

In this Office Action, the Examiner withdrew the prior rejection recognizing that 
deficiencies of Viswanath. For example, the Examiner recognized that the semantic verification 
and syntactic validation mechanism of Viswanath fails to provide any mechanism for applying 
implementation-specific configuration policies that comprises a set of rules representing the 
specific operational requirements of the particular networks within which the network device 
operates, as recited by independent claim 1. Office Action, pg. 3. 

However, the Examiner asserted that such features are taught by Kanada and that one of 
ordinary skill would modify the semantic verification and syntactic validation mechanism of 
Viswanath with the teachings of Kanada, in order to arrive at the claimed invention. In 
particular, the Examiner pointed to Kanada's teaching that a "router uses policy rules in QoS 



4 id H [0026]. 

5 Id. 1 [0008]. 



3 



Application Number 10/824,276 

Response to Office Action mailed 1 1/28/2008 

control, access control, and so forth," 6 and that the policy server of Kanada "provides a set of 
policy rules." 7 

The Examiner's argument is in error. Claim 1 recites applying an implementation- 
specific configuration policy to validate the changed candidate configuration data , wherein the 
implementation-specific configuration policy comprises a set of rules representing the specific 
operational requirements of the particular networks within which the network device operates. 
Even in combination, the only mechanism taught by either Viswanath or Kanada for validating 
changed configuration data are the semantic verification and syntactic validation mechanisms of 
Viswanath. 

To be clear, the policy rules taught by Kanada are not similar or analogous to the 
implementation-specific configuration policy of claim 1 , as indicated by the Examiner. Instead, 
the policies of Kanada are data for the router that specify the actions that the router will take 
upon the occurrence of a given condition when acting upon packets. 8 In other words, the 
Kanada policy rules specify what the router does with network traffic and are applied by the 
router to network traffic when the traffic is received . 

By contrast, the implementation-specific configuration policy recited by claim 1 
comprises a set of rules representing specific operational requirements applied to configuration 
data (not network traffic as in Kanada) to validate the changed configuration data in view of the 
operational requirements (not to forward traffic as in Kanada). That is, the implementation- 
specific configuration policies of claim 1 are applied by the router to candidate 
configuration data when that configuration data is received in order to validate it 
accordingly . 

Because Kanada does not disclose applying a configuration policy to configuration data, 
let alone applying an implementation-specific configuration policy comprising a set of rules 
representing specific operational requirements to validate the configuration data, it is still unable 
to overcome the deficiencies of Viswanath already identified by the Applicant in the previous 
response and admitted by the Examiner. The Examiner's new proposed modification of 
Viswanath in view of Kanada would not lead to Applicant's invention. Instead, the resultant 
network device would use semantic verification and syntactic validation of configuration data as 

6 Kanada at H [0042]. 

7 Kanada at \\ [0040]-[0044], 
"Kanada at 1) [004 1], [0039]. 
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taught by Viswanath, and would use policy rules to specify actions that the router must perform 
when forwarding traffic as taught by Kanada. The resultant network device based on the 
combined teachings of Viswanath in view of Kanada would still validate configuration data 
using only syntax and semantics (i.e., grammar and meaning). There simply is no teaching in 
any of the references, even when combined, as to validating configuration data in light of 
implementation-specific operational requirements of a network, as required by the claim. 
Consequently, the network device resulting from the combined teachings of Viswanath and 
Kanada would still only identify syntax and semantic errors in configuration data and would nat_ 
identify errors in configuration that was syntactically and semantically correct but would 
otherwise configure the network device in a manner that violates an implementation-specific 
operational requirement, such as configuring the device in a a way that would exceed quality of 
service limits set by a service level agreement. Present Application, [0026]. The prior art is 
wholly deficient in teaching a mechanism to validate configuration data in this regards, and the 
routing policies used by Kanada to forward traffic provide no additional teaching in this area. 

Claims 2-3, 16-17, and 29-30 

In the Applicant's response to the prior office action, dated May 15, 2008, Applicant 
demonstrated the inability of Viswanath to sustain a § 102 rejection of these claims and its 
failure to teach certain elements of Applicant's dependent claims. In the most recent office 
action, dated November 28, 2008, the Examiner did not address the Applicant's arguments. 
Instead, the Examiner simply repeated his earlier arguments, this time in the context of a § 1 03 
rejection of these claims. 

Applicant again submits that Viswanath does not teach or suggest the elements of claim 2 
of identifying an error within the changed candidate configuration data based on the 
implementation-specific configuration policy; and correcting the error by automatically altering 
the changed candidate configuration data in response to the identified error. 

Similarly, Viswanath does not teach or suggest the elements of claim 3 of correcting a 
warning condition by automatically altering the changed candidate configuration data. As 
already explained in regard to claim 1 , neither Viswanath nor Kanada teaches an 
implementation-specific configuration policy, let alone identifying an error within the changed 
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candidate configuration data based on such a policy. In addition, Viswanath FIG. 12 as cited by 
the Examiner does not support a rejection of these claims. 

With regard to claim 2, in the only proffered example in the Viswanath specification, 
"handling] the error," per Viswanath FIG. 12, in the changed candidate configuration data 
comprises throwing an exception. 9 Contrary to the Examiner's argument, there is nothing in this 
portion of the reference that suggests correcting an error by automatically altering the changed 
candidate configuration data . The Examiner's rejection on this matter is wholly improper. 

With regard to claim 3, although the Examiner cited Viswanath FIG. 12 as disclosing this 
feature, the components of that feature disclose only identifying a warning condition and 
notifying the user of such this condition. 10 There is nothing in the reference to suggest 
automatically altering the changed candidate configuration data, as required by Applicants' 
claims. Rather, the 'change' term used in Viswanath FIG. 12 and f [0153] (cited by the 
Examiner) refers to the "change request . . . initiated [by a user] to change the configuration 
data." 1 1 That is, once the warning is relayed to the user, the Viswanath method makes the 
requested change to the configuration data as originally requested by the user in spite of the 
warning. In the Applicants' claims, by contrast, the candidate configuration data is already 
changed ("changed candidate configuration data"). This change may lead to a warning condition 
that may be identified and corrected by the netw o rk device per claim 3. The Viswanath method 
does not apply an implementation-specific polity to correct the warning condition by 
automatically altering the changed candidate configuration data, as required by claim 3 in view 
of claim 1 . In fact, Viswanath the method does not make any corrections whatsoever. 

The cited references, therefore, does not teach or suggest at least these elements of claims 
2-3 and therefore does not support the Examiner's obviousness rejection. The Examiner has 
repeatedly failed to find a reference that teaches these elements, and Applicant requests that the 
Examiner withdraw his rejection. 



9 Viswanath \ [0153], 

10 Id. 

" Viswanath Tf [01 52], 
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Summary 

For at least these reasons, the references fail to establish a prima facie case for non- 
patentability of Applicant's claims 1-40 under 35 U.S.C. 103(a). Withdrawal of this rejection is 
requested. 



All claims in this application are in condition for allowance. Applicant respectfully 
requests reconsideration and prompt allowance of all pending claims. Please charge any 
additional fees or credit any overpayment to deposit account number 50-1778. The Examiner is 
invited to telephone the below-signed attorney to discuss this application. 



CONCLUSION 
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